Modeling and simulation tools may allow a developer to design, simulate, implement, and/or test control, signal processing, communications, and other time-varying systems. These modeling tools may represent a system with a graphical model having at least one entity. Values being input to the system may then be propagated through the graphical model during simulation of the graphical model. Input value(s) may be propagated through entities within the graphical model by having each entity receive an input value(s), manipulate the input value(s) in accordance with the defined behavior of the entity, and produce a finalized result in the form of an output value(s). This finalized result may then be propagated as input value(s) to any connected next entity(ies) in the graphical model. Once propagation is complete, code may be generated. However, if an input value(s) to the system is changed after the propagation is complete, the simulation must be re-started so that the changed input value(s) may be propagated through the graphical model.
FIGS. 12A-12D depict an exemplary propagation operation according to the prior art. In FIG. 12A, the depicted graphical model 1201A may include an input block 1202, an input block 1203, an input block 1204, a multiplexer (Mux block) 1205, a sum block 1206, and an output block 1207. Dimensional values of ‘4’, ‘2’, and ‘2’ may be received by input blocks 1202, 1203, and 1204, respectively. FIG. 12B depicts the Mux block 1205. Dimensional values may be propagated through Mux block 1205, for example, according to the rule: dim(Y1)=dim(U1)+dim(U2) (hereinafter rule 1). FIG. 12C depicts the sum block 1206. Dimensional values may be propagated through sum block 1206, for example, according to the rule: dim(Y1)=dim(U1) and dim(Y1)=dim(U2) (hereinafter rule 2).
In FIG. 12D, the depicted graphical model may be simulated. During propagation, the input numerical values ‘4’, ‘2’, and ‘2’ may be provided to the system and propagated through Mux block 1205 and sum block 1206 in accordance with rules 1 and 2. Specifically, dim(In)1=4, dim(In2)=2, and dim(In3)=2. With respect to the Mux Block 1205, according to rule 1, dim(Sig1)=dim(In2)+dim(In3)=2+2=4. With respect to the sum block 1206, according to rule 2, dim(Out1)=dim(Sig1)=4 and dim(Out1)=dim(In1)=4. Because rule 2 is not violated, i.e. dim(Sig1)=4 and dim(Out1)=dim(In1)=4, there is no conflict. Notably, only numeric values, not representations thereof, can be provided and propagated through the system.
FIGS. 13A and 13B depict two exemplary realizations of code based on the model in FIG. 12D. Both FIGS. 13A and 13B may be comprised of two files, the model.h file and the model.c file. The model.h file for both FIGS. 13A and 13B begin by defining the dimensional properties of signals ‘In1,’ ‘In2,’ and ‘In3’ as ‘4,’ ‘2,’ and ‘2,’ respectively, which are then used in lines 40-43 to define the output value. The model.c files of FIGS. 13A and 13B contain two potential descriptions of the operation of the Mux block 705 and the sum block 706. Notably, the propagated attributes in FIGS. 13A and 13B have been finalized. Thus, in order to re-target the model to a different set of attributes, attribute propagation and code generation must be re-started.
Conventional modeling and simulation tools may provide the ability to represent a specific property in a model with a symbolic expression. The symbolic expression may be specified by a default setting and/or by a user. However, the symbolic expression is generally limited to a single entity in the model, e.g. a block, and must be substituted with an actual value prior to the simulation of the model. Thus, the symbolic expression cannot be propagated through the graphical model. The conventional modeling and simulation tools may also require significant support in the form of memory or execution overhead and the code may need to be regenerated when used for different applications.